JBoss Community Archive (Read Only)

SwitchYard 0.7

Gateway Bindings

SOAP Bindings

The SOAP component in SwitchYard provides SOAP-based web service binding support for services and references in SwitchYard. 

Binding Services with SOAP

Composite-level services can be exposed as a SOAP-based web service using the <binding.soap> binding definition.  The following configuration options are available for binding.soap when binding services:

  • wsdl : location of the WSDL used to describe the web service endpoint.  A relative path can be used if the WSDL is included in the deployed application.  If the WSDL is located outside the application, then a file: or http: URL can be used.

  • socketAddr : the IP Socket Address to be used. The value can be in the form hostName/ipAddress:portNumber or hostName/ipAddress or :portNumber.

  • wsdlPort : port name in the WSDL to use.  If unspecified, the first port definition in the WSDL is used for the service endpoint

  • contextPath : additional context path for the SOAP endpoint. Default is none.

In AS7 by default the JBossWS-CXF stack is enabled now and hence the socketAddr parameter will be ignored. However this parameter can be used for standalone usage under JDK's JAXWS-RI.

Here's an example of what a SOAP service binding looks like: 

<sca:composite name="orders" targetNamespace="urn:switchyard-quickstart-demo:orders:0.1.0">
    <sca:service name="OrderService" promote="OrderService">
        <soap:binding.soap>
            <soap:wsdl>wsdl/OrderService.wsdl</soap:wsdl>
            <soap:socketAddr>:9000</soap:socketAddr>        
         </soap:binding.soap>
    </sca:service>
</sca:composite>

Binding References with SOAP

Binding a reference with SOAP can be used to make SOAP-based web services available to SwitchYard services. The following configuration options are available for binding.soap when binding references:

  • wsdl : location of the WSDL used to describe the web service endpoint.  A relative path can be used if the WSDL is included in the deployed application.  If the WSDL is located outside the application, then a file: or http: URL can be used.

  • wsdlPort : port name in the WSDL to use.  If unspecified, the first port definition in the WSDL is used for the service endpoint.

  • endpointAddress : the SOAP endpoint address to override from that specified in the WSDL. Optional property, if not specified will use the one specified in the WSDL. 

<sca:composite name="orders" targetNamespace="urn:switchyard-quickstart-demo:orders:0.1.0">
    <sca:reference name="WarehouseService" promote="OrderComponent/WarehouseService" multiplicity="1..1">
         <soap:binding.soap>
            <soap:wsdl>wsdl/OrderService.wsdl</soap:wsdl>
            <soap:endpointAddress>http://www.change.com/toanewendpointurl</soap:endpointAddress>
         </soap:binding.soap>
    </sca:reference>
</sca:composite>

Camel Bindings

Camel binding support in SwitchYard allows Camel components to be used as gateway bindings for services and references within an application.

Binding Services with Camel

Since SwitchYard 0.7 every camel component binding supported by runtime have it's own configuration namespace. However, there is small except. Binding for direct, seda, timer and mock share same namespace urn:switchyard-component-camel-core:config:1.0.

Composite-level services can be bound to a Camel component using the <binding.uri> binding definition.  The following configuration options are available for binding.uri:

  • configURI : contains the Camel endpoint URI used to configure a Camel component instance

  • operationSelector : specification of the operation to use for the message exchange. See Operation Selector for more details. This setting is not used for cxfrs configurations.

    binding.uri is not linked with any specific component. It allows usage of 3rd party camel components which are not part of distribution.

    Before SwitchYard 0.7 binding.camel element was used instead of binding.uri

Here's an example of what a service binding looks like using a Camel component. 

<sca:composite name="SimpleCamelService" targetNamespace="urn:userguide:simple-camel-service:0.1.0">
    <sca:service name="SimpleCamelService" promote="SimpleComponent/SimpleCamelService">
        <camel:binding.uri configURI="file://target/input?fileName=test.txt&amp;initialDelay=50&amp;delete=true">
            <selector:operationSelector operationName="print"/>
        </camel:binding.uri>
    </sca:service>
    <!-- sca:component definition omitted -->
</sca:composite>

Binding References with Camel

Binding a reference with Camel is very similar to binding a service.  The only significant difference is that specification of the operationSelector is not required on reference bindings. Logically reference elements points to outgoing communication eg. service called by Switchyard. 

<sca:composite name="orders" targetNamespace="urn:switchyard-quickstart-demo:orders:0.1.0">
    <sca:reference name="WarehouseService" promote="OrderComponent/WarehouseService" multiplicity="1..1">
        <camel:binding.uri configURI="file://target/output"/>
    </sca:reference>
</sca:composite>

HornetQ Bindings

The HornetQ gateway allows you to send and receive messages via a HornetQ queue.

Binding Services with HornetQ

Composite-level services can be bound to a HornetQ queue using the <binding.hornetq> binding definition.  The following configuration options are required for binding.hornetq:

  • connector : provides connection details for communicating with the HornetQ server.

  • operationSelector : specification of the operation name to use for the message exchange.  If the target service only has a single operation, this setting is optional.

Additional HornetQ binding configuration options can be found in the HornetQ config schema.  Here's an example of what a service binding looks like using a Camel component: 

<sca:composite name="HornetQServiceExample" targetNamespace="urn:userguide:hornetq-example-service:0.1.0">
    <sca:service name="HornetQService" promote="SomeService">
        <hornetq:binding.hornetq>
            <hornetq:operationSelector operationName="greet"/>
            <hornetq:config>
                <hornetq:connector>
                   <hornetq:factoryClass>org.hornetq.core.remoting.impl.invm.InVMConnectorFactory</hornetq:factoryClass>
                </hornetq:connector>
                <hornetq:queue>jms.queue.ServiceQueue</hornetq:queue>
            </hornetq:config>
        </hornetq:binding.hornetq>
    </service>
    <!-- sca:component definition omitted -->
</sca:composite>

Binding References with HornetQ

Binding a reference with HornetQ is very similar to binding a service.  The only significant difference is that specification of the operationSelector is not required on reference bindings. 

<sca:composite name="HornetQReferenceExample" targetNamespace="urn:userguide:hornetq-example-reference:0.1.0">
    <sca:reference name="HornetQReference" promote="SomeComponent/SomeServiceReference" multiplicity="1..1">
        <hornetq:binding.hornetq>
           <hornetq:config>
              <hornetq:connector>
                 <hornetq:factoryClass>org.hornetq.core.remoting.impl.invm.InVMConnectorFactory</hornetq:factoryClass>
              </hornetq:connector>
              <hornetq:queue>jms.queue.ReferenceQueue</hornetq:queue>
           </hornetq:config>
        </hornetq:binding.hornetq>
    </sca:reference>
</sca:composite>

JCA Bindings

The JCA gateway allows you to send and receive messages to/from EIS via JCA ResourceAdapter.

Binding Services with JCA message inflow

Composite-level services can be bound to a EIS with JCA message inflow using the <binding.jca> binding definition.  The following configuration options are required for binding.jca:

  • operationSelector : specification of the operation to use for the message exchange. See Operation Selector for more details.

  • inboundConnection

    • resourceAdapter

      • @name : Name of the ResourceAdapter archive. Please make sure the resource adapter has been deployed on JBoss application server before you deploy the SwitchYard application which has JCA binding.

    • activationSpec

      • property : Properties to be injected into ActivationSpec instance. Required properties are specific to the ResourceAdapter implementation.

  • inboundInteraction

    • listener : FQN of the listener interface. When you use JMSEndpoint, javax.jms.MessageListener should be specified. When you use CCIEndpoint, javax.resource.cci.MessageListener should be specified. Otherwise, you may need to specify EIS specific listener interface according to its ResourceAdapter. Note that the endpoint class should implement this listener interface.

    • endpoint

      • @type : FQN of the Endpoint implementation class. There are 2 built-in Endpoint, org.switchyard.component.jca.endpoint.JMSEndpoint and org.switchyard.component.jca.endpoint.CCIEndpoint. Note that these 2 have corresponding listener. If neither JMSEndpoint nor CCIEndpoint is applicable for the EIS you're supposed to bind to, then you need to implement its own Endpoint class according to the ResourceAdapter implementation. The Endpoint class should be a subclass of org.switchyard.component.jca.endpoint.AbstractInflowEndpoint.

      • property : Properties to be injected into Endpoint class. JMSEndpoint has no required property. CCIEndpoint needs connectionFactoryJNDIName property.

    • transacted : The boolean value to indicate whether transaction is needed by endpoint or not. True by default.

Here's an example of what a JCA service binding looks like. This example binds a service to the HornetQ JMS: 

<sca:composite name="JCAInflowExample" targetNamespace="urn:userguide:jca-example-service:0.1.0">
    <sca:service name="JCAService" promote="SomeService">
        <jca:binding.jca>
            <selector:operationSelector operationName="onMessage"/>
            <jca:inboundConnection>
                <jca:resourceAdapter name="hornetq-ra.rar"/>
                <jca:activationSpec>
                    <jca:property name="destinationType" value="javax.jms.Queue"/>
                    <jca:property name="destination" value="ServiceQueue"/>
                </jca:activationSpec>
            </jca:inboundConnection>
            <jca:inboundInteraction>
                <jca:listener>javax.jms.MessageListener</jca:listener>
                <jca:endpoint type="org.switchyard.component.jca.endpoint.JMSEndpoint"/>
                <jca:transacted>true</jca:transacted>
            </jca:inboundInteraction>
        </jca:binding.jca>
    </service>
    <!-- sca:component definition omitted -->
</sca:composite>

Binding References with JCA outbound

Composite-level references can be bound to a EIS with JCA outbound using the <binding.jca> binding definition.  The following configuration options are required for binding.jca:

  • outboundConnection

    • resourceAdapter

      • @name : Name of the ResourceAdapter archive. Please make sure the resource adapter has been deployed on JBoss application server before you deploy the SwitchYard application which has JCA binding.

    • connection

      • @jndiName : JNDI name which the ConnectionFactory is bound into.

  • outboundInteraction

    • connectionSpec : Configuration for javax.resource.cci.ConnectionSpec. Note that JMSProcessor doesn't use this option.

      • @type : FQN of the ConnectionSpec implementation class.

      • property : Properties to be injected into ConnectionSpec instance. 

    • interactionSpec : Configuration for _javax.resource.cci.InteractionSpec. _Note that JMSProcessor doesn't use this option.

      • @type : FQN of the InteractionSpec implementation class.

      • property : Properties to be injected into InteractionSpec instance.

    • processor

      • @type : FQN of the class which processes outbound delivery. There are 2 build-in processor, org.switchyard.component.jca.processor.JMSProcessor and org.switchyard.component.jca.processor.CCIProcessor. If neither JMSProcessor nor CCIProcessor is applicable for the EIS you're supposed to bind to, then you need to implement its own processor class according to the ResourceAdapter implementation. Note that this class should be a subclass of org.switchyard.component.jca.processor.AbstractOutboundProcessor.

      • property : Properties to be injected into processor instance. JMSProcessor needs destination property to specify target destination. CCIProcessor needs recordClassName property to specify record type to be used to interact with EIS. If you use CCIProcessor with the record type other than MappedRecord and IndexedRecord, you need to implement corresponding RecordHandler. Please refer to org.switchyard.component.jca.processor.cci.IndexedRecordHandler and org.switchyard.component.jca.processor.cci.MappedRecordHandler.

Here's an example of what a JCA reference binding looks like. This example binds a reference to the HornetQ JMS: 

<sca:composite name="JCAReferenceExample" targetNamespace="urn:userguide:jca-example-reference:0.1.0">
    <sca:reference name="JCAReference" promote="SomeComponent/SomeReference" multiplicity="1..1">
        <jca:binding.jca>
            <jca:outboundConnection>
                <jca:resourceAdapter name="hornetq-ra.rar"/>
                <jca:connection jndiName="java:/JmsXA"/>
            </jca:outboundConnection>
            <jca:outboundInteraction>
                <jca:processor type="org.switchyard.component.jca.processor.JMSProcessor">
                    <jca:property name="destination" value="ReferenceQueue"/>
                </jca:processor>
            </jca:outboundInteraction>
        </jca:binding.jca>
    </sca:reference>
</sca:composite>

RESTEasy Bindings

The RESTEasy component in SwitchYard provides REST-based binding support for services and references in SwitchYard. 

Binding Services with RESTEasy

Composite-level services can be exposed as a REST-based service using the <binding.rest> binding definition.  The following configuration options are available for binding.rest when binding services:

  • interfaces : A comma seperated list of interfaces or abstract/empty classes with JAX-RS annotations.

  • contextPath : Additional context path for the REST endpoint. Default is none.

Here's an example of what a REST service binding looks like: 

<sca:service name="OrderService" promote="OrderService/OrderService">
    <rest:binding.rest>
        <rest:interfaces>org.switchyard.quickstarts.rest.binding.OrderResource,org.switchyard.quickstarts.rest.binding.TestResource</rest:interfaces>
        <rest:contextPath>rest-binding</rest:contextPath>
    </rest:binding.rest>
</sca:service>

Binding References with RESTEasy

Binding a reference with REST can be used to make REST-based services available to SwitchYard services. The following configuration options are available for binding.rest when binding references:

  • interfaces : A comma seperated list of interfaces or abstract/empty classes with JAX-RS annotations.

  • address : A URL that points to the root path of resources. This is only applicable for Reference bindings. It is optional and if not specified will default to http://127.0.0.1:8080/.

  • contextPath : Additional context path for the REST endpoint. Default is none.

Here's an example of what a REST reference binding looks like: 

<sca:reference name="Warehouse" promote="OrderService/Warehouse" multiplicity="1..1">
    <rest:binding.rest>
        <rest:interfaces>org.switchyard.quickstarts.rest.binding.WarehouseResource</rest:interfaces> 
        <rest:address>http://localhost:8080</rest:address>
        <rest:contextPath>rest-binding</rest:contextPath>
    </rest:binding.rest>
</sca:reference>

In this example above the resource URLs will start from http://localhost:8080/rest-binding.

HTTP Bindings

The HTTP component in SwitchYard provides HTTP-based binding support for services and references in SwitchYard. 

Binding Services with HTTP

Composite-level services can be exposed as a HTTP-based service using the <binding.http> binding definition.  The following configuration options are available for binding.rest when binding services:

  • operationSelector : specification of the operation to use for the message exchange. See Operation Selector for more details.

  • contextPath : A context path for the HTTP endpoint.

Here's an example of what a HTTP service binding looks like: 

<sca:service name="QuoteService" promote="StockService/QuoteService">
    <http:binding.http>
        <selector:operationSelector operationName="getPrice"/>
        <http:contextPath>http-binding/quote</http:contextPath>
    </http:binding.http>
</sca:service>

Binding References with HTTP

Binding a reference with HTTP can be used to make HTTP-based services available to SwitchYard services. The following configuration options are available for binding.http when binding references:

  • address : A URL that points to the HTTP endpoint. It is optional and if not specified will default to http://127.0.0.1:8080/.

  • method : The HTTP method used for invoking the endpoint. Default is GET.

  • contentType : The HTTP Content-Type header that needs to be set on the request.

Here's an example of what a REST reference binding looks like: 

<sca:reference name="Symbol" promote="StockService/SymbolService" multiplicity="1..1">
    <http:binding.http>
        <http:address>http://localhost:8080/http-binding/symbol</http:address>
        <http:method>POST</http:method>
        <http:contentType>text/plain</http:contentType>
    </http:binding.http>
</sca:reference>

JBoss.org Content Archive (Read Only), exported from JBoss Community Documentation Editor at 2020-03-13 09:47:13 UTC, last content change 2012-09-20 05:46:31 UTC.